Hybrid application clients are now applied widely on mobile terminals because they have the advantage of both native app clients and web app clients. A Hybrid application client appears to be a native application operating on a mobile terminal such as a smartphone, yet accesses a web page provided by a server.
FIG. 1 is a flowchart illustrating a process whereby a Hybrid application client provides service to a user in a conventional system.
At 101, a Hybrid application client uses a predetermined Universal Resource Locator (URL) as a basis for sending a HyperText Transport Protocol (HTTP) request including the URL to a server. In other words, the Hybrid application client accesses the page corresponding to the predetermined URL.
At 102, the server sends HyperText Markup Language (HTML) code (e.g., HTML 5 code) back to the Hybrid application client.
At 103, the Hybrid application client analyzes the HTML code and determines the JavaScript file or Cascading Style Sheet (CSS) file that the HTML code is going to call. Specifically, the HTML code includes the JavaScript identifier or CSS identifier which will be for calling. It is used to identify the JavaScript or CSS that is to be called.
At 104, the Hybrid application client acquires from the server the JavaScript or CSS that is to be called.
At 105, the Hybrid application client uses the acquired JavaScript or CSS to call the Application Programming Interface (API) native to the client.
At 106, the Hybrid application client uses the called API to activate the appropriate feature of the mobile terminal where it is located.
Because mobile terminal features cannot be enabled by simply one JavaScript or CSS, the API that is natively saved by the Hybrid application client is needed for enabling these features. Therefore, the Hybrid application client, to enable the appropriate functions of the mobile terminal where it is located, must acquire JavaScript or CSS based on the HTML code and then call the native API through the JavaScript or CSS which was acquired.
For example, the Hybrid application client provides a camera feature, which has a corresponding resource, namely a JavaScript file saved in the server is photoV2.0.js. This file provides parameters associated with the onboard camera, such as pixel size, maximum number of photos that can be taken with one click, etc. The API file saved in the Hybrid application client is photoV2.0.jar. Thus, the Hybrid application client first accesses the server page, determines that the JavaScript file, which the HTML5 code sent back by the server, is going to call photoV2.0.js, thus acquires photoV2.0.js from the server, and via photoV2.0.js calls its own Java functions photoV2.0.jar to enable the camera of the mobile terminal where the hybrid app is located.
To provide normal service by the hybrid app, the version of the Hybrid application client should be the same as the server's version. If the Hybrid application client's version is different from the server's version, the Hybrid application client will typically fail to provide service normally.
For example, the Hybrid application client provides a camera picture-taking feature. The Hybrid application client's version is V1.0, therefore the API saved on the Hybrid application client is photoV1.0.jar (the API version saved in the Hybrid application client is the same as the Hybrid application client's own version). If the server version is V2.0, then the JavaScript saved in the server is photoV2.0.js. Thus, the JavaScript that is to be called by the HTML5 code sent back by the server to the Hybrid application client is photoV2.0.js. After the Hybrid application client acquires photoV2.0.js, because photoV2.0.js can only call an API with the same version V2.0 (i.e., photoV2.0.jar), the version that is saved in the Hybrid application client is the V1.0 API (i.e., photoV1.0.jar). Consequently, the Hybrid application client cannot obtain an API with the corresponding version (V2.0) via photoV2.0.js, and therefore cannot provide the camera picture-taking feature normally.
Not every user will promptly update the Hybrid application client version installed on his or her mobile terminal. Therefore, in existing systems, to solve the aforesaid problem of the Hybrid application client not being able to provide service normally when the Hybrid application client and the server have different versions, the Hybrid application client can save all API JavaScript or CSS (JavaScript and CSS are collectively referred to below as “current resources”) natively under its own current version. When the Hybrid application client receives HTML code sent back by the server, if it determines that the version of the current resource to be called by the HTML code is inconsistent with the native version of the hybrid app, it replaces the identifier of the current resource that is to be called in the HTML code with the identifier of the current resource of the natively saved version, analyzes the HTML code after the current resource identifier has been substituted, and calls the substituted current resource in order to achieve corresponding feature.
For example, the Hybrid application client provides a camera picture-taking feature. The Hybrid application client's version is V1.0, so the API saved on the Hybrid application client is photoV1.0.jar. In addition, the current resource (JavaScript) photoV1.0.js, which can call photoV1.0.jar, is saved in the Hybrid application client. The server version is V2.0, and the JavaScript file saved in the server is photoV2.0.js.
Thus, the JavaScript file that is to be called by the HTML code sent back by the server to the Hybrid application client is photoV2.0.js. When the Hybrid application client determines that the JavaScript identifier included in the HTML code is photoV2.0.js, it substitutes the natively saved photoV1.0.js identifier (which corresponds to the photoV2.0.js but whose version is different) for the photoV2.0.js identifier in the HTML code. It then analyzes the HTML code and calls the natively saved photoV1.0.js on the basis of the substituted identifier (the identifier for photoV1.0.js). It does not acquire resources from the server. Finally, the Hybrid application client calls the natively saved photoV1.0.jar via photoV1.0.js so as to enable the camera feature of the mobile terminal.
However, in the existing scheme, the Hybrid application client needs to substitute the identifier for the photoV1.0.js that it saved for the photoV2.0.js identifier in the HTML code sent back by the server. This will alter the original structure of the HTML code. When the HTML code is HTML5, the substitution will invalidate the HTML5 code's own app cache feature and thus give rise to likely errors when subsequent web pages are loaded based on HTML code.